Summary
A monolith packages functionality into one deployable system. Microservices split the system into independently deployable services around business capabilities.
Interview Points
- Monoliths are simpler to develop, test, deploy, and observe early on.
- Microservices help with independent scaling, ownership, and release cadence.
- Microservices add network calls, distributed transactions, observability, and operational overhead.
- Split by domain boundaries, not by technical layers.
- A modular monolith is often the best starting point.
2-3 Minute Interview Script
“I do not treat monolith versus microservices as good versus bad. A monolith is often the right starting point because it keeps development, testing, transactions, and deployment simple.
Microservices become useful when team ownership, independent scaling, reliability isolation, or release independence become more important than the simplicity of one deployable unit.
The danger is splitting too early. If boundaries are unclear, microservices create distributed complexity without business value: network failures, duplicated models, difficult debugging, and data consistency problems.
In an interview, I would propose a modular monolith first, with clean domain boundaries. Then extract services when a boundary is stable and there is a clear scaling or ownership reason.”
Follow-Ups
- What is a modular monolith?
- How do services share data?